Timing packets are used in packet networks to distribute timing reference information. The protocols most commonly used are Network Time Protocol (NTP) and Precision Time Protocol (PTP), defined in IEEE1588. The timing performance that can be achieved by means of this technology is impacted by packet delay variation (PDV), for example due to congestion in the packet network. This can severely impact the performance of the network, e.g. a mobile network.
Packet timing e.g. using IEEE1588, is used to distribute synchronization to radio base stations. This is used for the basic operations of any radio access technologies, e.g. LTE (Long-Term Evolution) or LTE-Advanced. Frequency synchronization is required; and time synchronization requirements are increasing, for example, to support Time-division duplexing (TDD) or LTE coordination features. IEEE1588 specifies a protocol and a mechanism to distribute timing reference over a packet network.
FIG. 1 shows an example PTP (IEEE1588) network 100. The network 100 comprises different types of clocks, e.g. a Grandmaster clock 101, Ordinary Clocks 102 and Boundary Clocks 103. Timing information is passed between clocks acting as a Master (labelled ‘M’) 105 and a Slave (labelled ‘S’) 104. The clocks are arranged to use an exchange of two-way PTP messages to establish a synchronization hierarchy and synchronize to the Grandmaster clock 101 of the network 100.
FIG. 2 shows an example of two-way PTP message exchange 110. A first message 111 or packet is sent from the Master to the Slave at time t1. This is referred to as a Sync message, and may be sent by the master to all the clocks in the domain. A clock receiving this message takes note of the local time t2 when this first message is received.
Optionally, the master subsequently sends a further message 113, referred to as Follow_Up, with an accurate timestamp of t1. This is applicable to a master which is only able to retrieve an accurate timestamp for the Sync transmission from their network hardware after the transmission is complete.
In order to accurately synchronize to their master, clocks must individually determine the network transit time of the Sync messages. The transit time is determined indirectly by measuring round-trip time from each clock to its master. The clocks initiate an exchange with their master designed to measure the transit time. The exchange begins with a clock (slave) sending a Delay_Req message 114 at time t3 to the master. The master receives and timestamps the Delay_Req at time t4 and responds with a Delay_Resp message 115. The master includes the timestamp t4 in the Delay_Resp message.
Through these exchanges a clock learns t1, t2, t3 and t4. The offset between the master and slave clocks is:Offset=(t2−t1+t3−t4)/2
In particular the distribution of timing via packets in a packet telecommunications network can be done via two main architectures. A first architecture is based on sending packets transparently across the network from a master (e.g. PTP master) to a slave. The master in case of mobile applications is typically located in the Switch site (as shown in FIG. 4) and the slaves are typically integrated in radio base stations. This architecture is suitable to distribute frequency synchronization. A second architecture described by ITU-T G.8275 has been defined specifically to support time synchronization. In this case every node terminates and/or processes the timing packets.
FIG. 3 shows an example of the first architecture for a network 120. A reference clock 121 provides a reference time for a master clock 122. The master clock 122 communicates with one or more slave clocks 123 through a packet network 125. Two-way communication by packets 127 provides for synchronization of the slave clocks. When delivering packets transparently over the network to carry timing information, the PDV created by the network (mainly due to queuing), can severely impact the performance of the service. Especially highly loaded networks (90%-100%) may generate a level of PDV that the slave is not able to tolerate.
The issue is that generally it is not known which links/nodes are actually creating the problem. Redundant masters may allow switching to a better quality reference, if the congestion has not impacted links which are common to both paths.
One way to solve such problem is to deploy extremely accurate and costly oscillators in the slaves.